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REMARKS 

Claims 1-6, 8-11, 13-21, and 23 are pending. No claims are amended, 
canceled, adding, or withdrawn. 

Withdrawal of the rejections to the pending claims is respectfully 
requested. 

35 use §103(a) Rejections 

Claims 1-6, 8-21, and 23 stand rejected under 35 USC §103fa) as being 
unpatentable over US patent number 6,609,161 to Young . These rejections are 
traversed. 

Claim 1 recites 

• "the method for managing a run queue comprising a first plurality of threads 
sorted with respect to one another based on thread priority", and 

• "in a deterministic amount of time equivalent to an amount of time to insert a 
single thread into the run queue, associating a second plurality of threads that is 
priority sorted with the run queue in a manner that maintains a priority based 
scheduling semantic of the run queue." 

In addressing these claimed features and Applicant's reasons why Young did not 
teach or suggest these claimed features (presented in the response dated August 
24, 2005), the "Response to Arguments" section at page 6 of the Action argues 
that the broadest reasonable interpretation of "run queue" is where 
"programs/processes/threads/commands are taken from the head of the queue to be 
executed or process[ed]". In view of this broad interpretation, the Action asserts 
that Young meets the limitation of "run queue". Applicant respectfiilly disagrees. 



11 



9C21DS-DOC 



During examination plain meaning is given to a claimed term unless the 
specification provides meaning for the term, whereupon which the specification 
must be used to identify the meaning ascribed to the term by the inventor. (MPEP 
§2111.01). In this case, the Action has not used either the plain meaning of the 
claimed term "run queue" or the expHcit definition provided by Applicant's 
specification. Instead the Action changes the plain and well-known meaning 
typically associated with a "run queue" by substituting its own interpretation that 
is completely contrary to the meaning that one of ordinary skill in the art at the 
time of invention would have given the term, and also completely contrary to what 
is described in the specification for the term. 

Specifically, it is well-known in the art that a "run queue" is not for 
storing rewind, write, compare, verify, or otlier SCSI commands", as the 
Action asserts. Rather, a "run queue" is for storing threads representing respective 
paths of execution through a computer-program (process) for execution by a 
computer. Not only was this plain meaning of the use of a "run queue" well- 
known at the time of invention, but it is also the use of a "run queue" described in 
Applicants specification. In view of this well-known plain meaning and 
specification supported description of the purpose of a "run queue", the Action's 
assertion that the claimed "run queue comprising a plurality of threads" is the 
same as Young's command queue used to store SCSI commands (i.e., not threads 
representing process execution paths) is not a reasonable assertion. 

Applicant respectfully submits that if Young tried to insert such SCSI 
rewind, write, compare, verify, or other commands into a "run queue", such 
insertion would likely harm runtime operation of any system that relied on the run 
queue to store threads representing a path of execution through a computer- 
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program process, rather than SCSI commands meant to be parsed by a SCSI 
compliant peripheral device. In such an illogical scenario, the system's thread 
scheduling mechanism would not encounter a thread, but would instead encounter 
a rewind, write, compare, verify, or other type of SCSI command. Clearly this 
command does not belong in a "run queue", but instead as Young teaches, is for 
sending to a target peripheral device. In view of this, Young does not teach a "run 
queue comprising a plurality of threads". Rather, Young teaches a SCSI command 
queue comprising SCSI commands for subsequent communication to a peripheral 
device. 

In view of the above plain and well-known meaning of the purpose of a 
"run queue", Applicant is not attempting to read limitations of the specification 
into the claims for purposes of avoiding prior art. Instead, Applicant is merely 
relying on a fundamental aspect of patent law that dictates that claimed subject 
matter cannot be examined in a vacuum. As §2111.01 states, a term must be 
examined in view of plain meaning unless the specification provides meaning for 
the term, whereupon which the specification must be used to identify the meaning 
ascribed to the term by the inventor. In this case, the Action has assigned a 
meaning to a term that is contrary not only to plain and well-ltnown meaning 
for the term, but also different than meaning given to the term by the 
inventor. In light of this, the Action is seemingly relying on personal knowledge 
to support this otherwise unsupported meaning ascribed to a claim feature. 

According to 37 CFR § 1.104(d)(2), "[w]hen a rejection in an application is 
based on facts within the personal knowledge of an employee of the office, the 
data shall be as specific as possible, and the reference must be supported, when 
called for by the applicant, by the affidavit of such employee, and such affidavit 
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shall be subject to contradiction or explanation by the affidavits of the applicant 
and other persons." In view of this, and regardless of whether the form of the 
Actions' rejection of claim 1 is proper under MPEP §706.02{j), if this rejection is 
maintained on a similar basis in a subsequent action, the Examiner is requested to 
supply such an affidavit to support this otherwise unsupported modification to the 
SCSI command queue of Young. Otherwise, and without additional support, it is 
respectfully submitted the Action's conclusion does not represent the conclusion 
of a person of ordinary skill at the time of invention, and thereby, cannot represent 
a "broadest reasonable interpretation" of a "run queue", as claim 1 requires. 

Withdrawal of the 35 USC § 103(a) rejection of claim 1 is requested. 

Additionally, claim 1 includes further features that are not taught or 
suggested by Young. For example, claim 1 also requires "threads". When 
addressing this feature, the Action at page 7 points out that the term "thread", as 
defined by Microsoft Computer Dictionary Fifth Addition, is "a process that is 
part of a larger process or program". Given this definition, the Action asserts that 
the "broadest reasonable interpretation" of a "thread" is met by "a SCSI command 
block". Applicant respectfully submits that this broad interpretation is clearly not 
reasonable, especially in light of the explicit definition provided by the referenced 
dictionary, which defines a thread as "a process [...]", not a command. 

Young, at column 2, lines 63-64, teaches that "[ejach command block 
includes a command for target device". Young describes at column 1, lines 12- 
16, that it example of such a control block is a SCSI command block (SCB) used 
to transfer information between a software host adapter bus driver and a peripheral 
device. Examples of SCSI commands include, for example, rewind, write, 
compare, verify, etc. In contrast to SCSI commands, it is well-known in the art 
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of computer-science and computer programming that a thread within the context 
within which it is used (i.e., "part of a larger process or program") is a part of a 
computer-program application that can execute independently of other parts of the 
computer-program application. In contrast to "threads", SCSI commands cannot 
execute independently of other parts of a computer-program application because 
SCSI commands are not representative of computer program language paths 
of execution. Instead, SCSI commands are blocks of information that upon being 
parsed, direct peripheral devices to perform some action such as rewind, verify, 
compare, etc. In view of these express teachings of Young, a "SCSI command 
block" is clearly not "a process", as required by the definition of a thread 
provided by the Action. Since a SCSI command is not a process, a SCSI 
command cannot be "a process that is part of a larger process or program". 

In view of the above. Young's express disclosure of a SCSI command does 
not meet the definition of a thread that was provided by the Action. Moreover, the 
scenario applied above to a "run queue" which is used to store threads can also be 
applied to show that a SCSI command is not a thread. Specifically, Applicant 
respectfully submits that if Young tried to insert a SCSI command into a system 
that typically stores threads into a "run queue", the inserted SCSI command block 
would at least temporarily incapacitate the runtime processing operations of the 
system. This is because SCSI commands such as rewind, write, verify, compare 
and other SCSI commands do not represent a path of execution in a computer 
program (i.e., a thread). In such an unlikely scenario, a thread scheduling 
mechanism would not encounter a thread as typically expected, but would instead 
find a command block of information for a target peripheral device. 
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This is another example of where the Office is seemingly using personal 
knowledge to modify the well-known and plain meaning of "threads" that are 
stored in a "run queue" by substituting SCSI commands for the threads. Not only 
are these modifications unsupported and contrary to the well-known and plain 
meaning of the claim term within its presented context, but also contrary to the 
clear descriptions of the term in Applicant's specification. 

Again, Applicant is not attempting to read limitations of the specification 
into the claims for purpose of avoiding prior art. Instead the Applicant is merely 
relying on the Office to follow the directions of MPEP §2111.01 and not examine 
the claims in a vacuum. Here, the Action has assigned meaning to "threads" that 
is not only contrary to plain meaning and what would have normally been ascribed 
to the term by a person of ordinary skill in the art at the time of invention, but also 
contrary to the written description of "threads" in Applicant specification. Thus, 
the Actions broad interpretation of the claimed term "threads" as being the same 
as SCSI commands is not reasonable and not representative of the meaning of the 
claimed feature of "threads", as claim 1 requires. 

For these additional reasons, withdrawal of the 35 USC §103 (a) rejection of 
claim 1 is requested. 

Claims 2-6 depend from claim 1 and are allowable over Young solely by 
virtue of this dependency. Accordingly, withdrawal of the 35 USC § 103(a) 
rejection of claims 2-6 is requested. 

Claim 8 recites 

• "[a] system for managing a run queue, the run queue comprising a first 
plurality of threads, each thread in the first plurality of threads having a 
respective priority, the first plurality of threads being sorted such that a thread 
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having a high priority is removed from the run queue before a thread having a 
lower priority", and 

• "in an amount of time to insert a single thread into the run queue, associating 
the second plurality of threads that is priority sorted with the run queue, the 
associating maintaining a priority based scheduling semantic of the run queue." 

For the reasons already discussed, Young does not teach or suggest these claimed 
features. 

Withdrawal of the 35 USC § 103(a) rejection of claim 8 is requested. 

Claims 9-11 and 13-15 depend from claim 8 and are allowable over Young 
solely by virtue of this dependency. Accordingly, withdrawal of the 35 USC 
§ 103(a) rejection of claims 9-11 and 13-15 is requested. 

Claim 16 recites 

• "computer-program instructions to manage a run queue of executable threads 
sorted with respect to one another based on thread priority", and 

• "in a deterministic amount of time that is independent of the number of threads 
in a second plurality of threads that is priority sorted, the deterministic amount 
of time being a time to insert a single thread into the run queue, associating the 
second plurality of threads with a first plurality of threads in the run queue in a 
manner that maintains a priority based scheduling semantic of the run queue." 

For the reasons already discussed, Young does not teach or suggest these claimed 
features. 

Withdrawal of the 35 USC § 103(a) rejection of claim 16 is requested. 
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Claims 17-21 depend from claim 16 and are allowable over Young solely 
by virtue of this dependency. Accordingly, withdrawal of the 35 USC § 103(a) 
rejection of claims 17-21 is requested. 

Claim 23 recites 

• "managing a run queue with a run queue data structure, the run queue data 
structure comprising: a first dimension data field comprising a first plurality of 
threads sorted with respect to thread priority", and 

• "a second dimension data field comprising a second plurality of threads sorted 
based on thread priority, the second plurahty of threads comprising a root 
thread and one or more other threads." 

For the reasons already discussed, Young does not teach or suggest these claimed 
features. 

Withdrawal of the 35 USC § 103(a) rejection of claim 23 is requested. 
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Conclusion 



Pending claSns 1-6, 8-11, 13-21, and 23 are in condition for allowance and 



4 action to that end is respectftilly requested. Applicant has left a voice message on 

5 the Examiner's telephone requesting a telephone mterview for this application. To 

6 avoid appeal of this case and move this case towards allowance, Applicant hopes 

7 that the Examiner will allow the pending subject niatter at least for the additional 

8 reasons provided above, or at least withdraw the finality of the last action and 

9 perform a new sekrch, if necessary. Should any issue reaiiain that prevents 
)o allowance of the application, the Office is encouraged to contact the undersigned 
! I prior or issuance of an advisory action. 

12 

u Respectfiilly Submitted, 




Brian G. Hart 
Reg. No. 44, 421 
(509) 324-9256 
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